Good catch, you're right that a plain deterministic SHA-256 prefix isn't privacy-safe for these inputs. I've reworked the hashing in createRetrievalReceipt:

• Each receipt now generates a fresh 32-byte random salt and keys an HMAC-SHA256 with it. The salt is never emitted in the receipt.
• Without the salt, the low-entropy values (query, container/project tag, memory IDs, short content) can no longer be dictionary-guessed or precomputed offline.
• Because the salt is regenerated per receipt, the same private value produces a different token every time, so values are no longer linkable across receipts.
• Equality is still preserved within a single receipt (e.g. duplicate IDs/content in one result set), which is what the debugging use case needs.

hashAlgorithm is now reported as hmac-sha256-ephemeral-salt-prefix-16, and I added a regression test covering both properties (intra-receipt equality and cross-receipt non-linkability). Let me know if you'd prefer a different trade-off here, e.g. dropping content hashes entirely or making the receipt opt-in behind a server-side flag rather than a per-call param.